從IaC 到佈署 - Azure DevOps Service

部署標的 - Environment

希望做到的效果

前面已經將Azure Repos設定完成之後，接下來就要來處理要佈署的環境了。因為所有的設定值，都是會被承載在某個環境中運行，我們稱之為維運環境。企業中的維運環境通常會依照不同軟體開發階段，被分屬在不同環境中。對開發人員而言，那是不同階段的產物。

但是對於維運人員而言，那就是不同環境。當然優先級別有差，所以有時候設備的等級、頻寬或是伺服器的等級與數量，都會以正式環境最為優先，而測試或是開發環境通常會次之。當這種差異出現後，就可以體現有一些設定值不見得可以被抽象出來，因為可能因為某些設定僅有正式環境才有，測試設備上根本就不存在這功能，因為設備等級比較低。

先不多言，先將我們要佈署位置的代理服務先建置起來，本次筆者都是在自己的筆記電腦中運行，讓筆者先簡單敘述希望達到的效果。

提醒： 如果讀者希望跟著範例走一遭，那請注意您的示範檔案運行環境一定與筆者的不同，因此要根據讀者自身環境進行調整，才能繼續實驗下去。

• 運行環境的目錄：C:\Users\samnc\IaC_Demo\SIT
  • docker-compose.yaml會將本系列文所有環境皆運行起來。
  • Kong_declarative\declarative\kong.yml 是kong運行所載入的設定檔，這是變更管理的標的。
  • kong.yml變更時，執行docker compose restart kong-dbless，這樣不會影響到其他服務。

安裝agent

圖21-1 Environment

首先先參考圖21-1 ，找到左方Environments的選單，並且按下Create environment的按鈕。

圖21-2 New environment

由於筆者的筆電是一般桌機，因此選擇Vairual machines，並按下Next。

圖21-3 Get the cmd and token

接下來圖21-3這步驟需要注意，因為紅色框起來的部分是一連串powershell指令，其中包含了PAT，而且僅有三小時有效期限。如果超過了三小時，上面這步驟就需要重來了。

圖21-4 install agent via powershell as admin

接下來，前一步驟複製下的指令，請以系統管理員開啟powershell，直接貼上複製好的指令，並按下執行(預設工作目錄會是C:\azagent)。

執行會需要一些時間，因為指令中會及時去抓取最新版本的pipeine agent，請耐心稍後一下。接下來所有指令都預設按下同意即可，這裡就不細談每一步驟的細節。

當完成後，可以回到Azure DevOps Service Environment的頁面上，切換到Resources的頁籤，就會看到剛才安裝主機的名稱出現在清單中，這代表已經完成佈署標的的agnet安裝了(參考圖21-5)。

圖21-5 安裝好的agent

到這，就已經準備好即將佈署的標的了。

補充：這裡要說明有關於pipeline agnet(又分self-hosted 與 ms-hosted)與environment agent的差異。

• pipeline agnet是為了代理pipeline執行某個任務，例如編譯、測試、打包、掃描等，通常僅需要一個代理協助，就可以完成任務。
• environment agent著重於管理與操作特定環境，常用於部署與維運階段。

這兩種最大的差異就是當yaml到environment agent執行deploy的行為時，預設會將指定環境的所有標的都執行佈署腳本。因為佈署這行為通常會預設該環境所有標的都被涵蓋，特別是企業中通常為了備援而準備了多台主機，甚至多個環境作為故障備援而使用。

因此佈署本就應將所有標的都進行，這樣在遇到及時災害時，才可以無痛的將備援主機推到前線，供業務單位使用。

Azure Pipelines

設定pipeline

圖21-6 Azure Pipelines

接下來要進行變更管理所需要的自動化流水線的設計了，這裡需要注意一下，因為這會需要團隊會共同定義哪一些工作必須要被建立起流水線。筆者曾經希望，在系統炸掉的那一天，可以靠著自動化流水線就從頭到尾建立回去。因此建立了兩條流水線，一條叫做每次變更管理都會使用到的流水線，另外一條則是開天闢地從零開始流水線。

結果變更管理流水線常常使用，開天闢地流水線初始建置使用了一次，然後還是要馬殺雞重新調整之後，再也沒用過了。因此筆者就在思考，哪一些工作適合是被建置在Pipeline中？最終認為有一個結論，那就是當這個變更行為是時常發生，且關係到團隊協作的持續整合與佈署的行為，那就很適合建立。開天闢地這種可能比較適合寫一個powershell放在專案的repo中，並被描述到readme.md中比較適合。

接下來，筆者將進行Pipeline的設定，可以先關注到圖21-7，讓我們先建立一個Pipeline。

圖21-7 Create Pipeline

接下來，會需要選擇Pipeline的腳本來源，請參考圖21-8，選擇Azure Repos Git。

圖21-8 Select pipeline code

下一步則是，選擇這次儲存的repo：Iac_Demo。

圖21-9 Iac_Demo

接者選擇Existing Azure Pipelines YAML file。

圖21-10 選擇現有的YAML file

最後選擇筆者這次撰寫的yaml，並按下繼續。

圖21-11 選擇SIT_Kong_sync.yaml

參考圖21-12，既然完成了，那就讓他跑跑看。

圖21-12 跑跑看

圖21-13 授權存取剛剛裝好的Environment

試跑的過程中，讀者應該會注意到跳出一個請求，就是希望可以讓這個腳本存取剛剛裝好的Environment。這是一個安全性許可的過程，當運行的腳本需要存取該腳本repo外的其他資源，如其他repo、variable groups、environment或是service connection等，基本上都會需要經過第一次的許可，目的最小授權存取的確認。

畢竟一段程式碼可以被運行在任何環境中，特別是企業的正式環境裡，如果不經許可就可以被運行，那想必資安人員一定會頭痛得要死。

圖21-14 執行成功

一切順利的話，相信讀者會看到pipeline執行成功的畫面。

如果執行失敗也不要緊，筆者明天會說明yaml內的相關設計，會將執行過程說明清楚。

今天也囉嗦了很多，明天見啦~